In the last lesson, we added electron builders auto update a module and successfully found the version
one release by building the app as a lower version, nought point nine.
That's all good.
But as we can see from the auto update logs, once that update was found on GitHub, it automatically
started downloading, not ideal.
As developers, we have a responsibility to at very least let the user know a download is about to happen
and when possible, also give them the option to postpone it.
So in this lesson, we'll add the user interface to do just that, notify the user of a new update and
give them the choice to start the download or postpone it.
Then, given the user accepts the update, will again do the same once the new update is ready to be
installed, meaning let the user decide whether they want to install the update by restarting the app.
Back in our local update, a module.
We can start this process by listening for an event that tells us the auto update has found a viable
update to download in the auto updated docs.
We have this event section in the table of contents and the event we are looking for here is update
available.
I'll copy the event name.
Listening on this auto update for update available, pass a call back.
In which will prompt the user to either download or postpone the update, but keep in mind that as we
saw in the previous lesson, as soon as this check for updates function finds an update, it automatically
started downloading it.
This defeats the point of our prompt.
So before implementing this prompt, we first have to disable auto downloads back in the docs again.
We see this mentioned here and if I scroll down a bit, we see properties of the auto updater with the
first being auto download, whether to download an update when it's found.
Copy that property name.
And right at the top here, as part of the initial configuration, we can disable auto downloading of
updates by setting on the auto update a module auto download that property name equal to false.
So this will now stop check for updates from downloading an update when it's found and instead allow
us to start that download manually in here, should the user agree?
Will implement the prompt in a second.
But back in the auto updated docks down to Method's, we have this download update, which is what will
use to manually start the download.
Calling Auto Updater Download update our comment that out for now, as we still need a prompt for which
I'll use Electron's dialogue module dialogue Duchow message box.
Not forgetting to require the dialogue module from electron.
Consed dialogue equals require electron.
There, I'll update these double quotes for uniformity.
Better and back to the message box dialogue, call this function passing in an options object with the
type being info, a dialogue title of update available.
Message being the more detailed explanation of what this dialogue is for, a new version of it is available.
Do you want to update now?
And lastly, buttons for capturing the user's choice.
This takes an array with the primary button being update meaning yes, go ahead and download update
or no, which will just postpone the update to the next time the app is launched.
Then finally, to read the user selection from these buttons, we can resolve the returned promise worth
then accessing in that resolvers callback as before the result object.
On which we can get the index of the selected button with the response property.
Then if the button index is zero being the update button, start downloading the update.
Button index equals zero, call this download update, function, any other button, and nothing will
happen.
So essentially dismissing the update download until the next app launch, we can test this first step.
I'll rebuild the app, leaving it as version nought point nine to ensure our version one update is found.
And done also before launching the app, I'll clear out that auto update, a log from the previous lesson,
echo an empty string to the log.
So just overwriting the log file with no content and then keep that log file open so we can observe
the logs on Mac and Linux.
You can do this with tail.
So printing the end of the log file with an F flag which keeps the tail print open, launch the newly
built up with that update dialog.
I'll immediately head over to the terminal.
Checking for update and a second later, version one is found with the dialogue causing the app icon
to bounce, telling us something has happened.
Check that.
And there we have the dialogue to either accept or postpone this available update.
No will, of course, just close the dialogue and nothing further will happen.
But if I say update, check the log downloading update redit version one.
So that works.
Should I now leave this download to finish?
What will happen is the next time the user quits the app, the update will be installed in the background,
ready for whenever the app is then launched again.
But we can again do better.
Instead, let's notify the user of the download being done, allowing them to immediately quit the app,
install the update and restart the app automatically thereafter.
This way, a user can be fully aware of any new features or fixes.
Back in our update.
A module.
Will now want to also listen for the download being ready.
Under the event's yeah, update downloaded, copy that event name.
Listening on Auto Updater for update downloaded, this event takes a call back in which will prompt
the user to install the update.
Using another dialogue called Show Message Box.
Type of info as before.
Update ready as this is now ready to be installed, the message can pose a question again, install
and restart now.
With two buttons of either, yes.
Or later, I say later, as dismissing this won't prevent the update from being installed, it will
just happen the next time the user quits and launches the app themselves as before.
Set a dialogue callback for the button click.
I'll copy this from the download prompt as we are checking the same button index.
In which will want to install and restart if the button index is zero, the yes button, but calling
on the auto updater quit and install this function takes two arguments over to the docks, back down
to Method's.
The first argument is silent, this basically toggles whether the installer window is seen when updating
the app on Windows and is Forche run after which sets whether to automatically restart the app after
the update is installed.
I'll set the first two false, so choosing to show the install a window when updating the app on Windows
and try to restart the app again after installing the update as the user selector to install and restart,
I'll save all of this to test.
Rebuild the same version, nought point nine to have the updated code.
That's done, launched the New Bold.
Still, version nought point nine, so version one should be found.
There we get the prompt update to start downloading the update, I'll speed it up a bit to get the download
done and a minute later we get that second prompt, allowing us to either keep working on version nought
point nine and only install the downloaded update when we next get the app or alternatively could install
and restart the app.
Now I'll say yes, which puts the app, installs the new version and automatically restarts it confirmed
that by checking the app version, which is now version one.
So our update was successful in the next and final distribution lesson will perform the complete process
of fixing a simple bug with auto updates for both Mac and Windows.